1. Technical Field
This invention relates to an interrupt handler for a hardware interrupt. More specifically, the invention relates to separating management of tasks in the interrupt handler based upon categorization of the task.
2. Description of the Prior Art
An interrupt is a signal informing a CPU that an event has occurred. The interrupt can be in the form of a software interrupt or a hardware interrupt. In one embodiment, the interrupt is a digital signal to a CPU that indicates some event has happened. When the CPU receives an interrupt, it takes a specified action. For example, an interrupt can cause the CPU to suspend an interruptible task to temporarily service the interrupt. Before the CPU can respond to an interrupt, the processor must wait for an interruptible state in its processing. For example, if the processor is writing to memory, it must wait until the write is completed before processing the interrupt. Once the informing CPU detects the interrupt, it must save all of the information it will need to resume normal processing of the interrupted task once the interrupt is over. An interrupt handler is a callback subroutine in an operating system or device driver whose execution is triggered by the receipt of an interrupt. After the event that caused the interrupt is complete, an interrupt service routine restarts the interruptible task from where it had previously been suspended.
FIG. 1 is a flow chart (100) of a prior art process for generating an interrupt and processing the associated event. An event is received by a processor that generates a hardware interrupt (102). The event may be in the form of a send event or a receive event. In one embodiment, the event may include a bit which identifies whether the originating event is a send event or a receive event. Upon receipt of the event a hardware interrupt is generated (104), and the received event is placed in a mixed interrupt event queue (106). Both send and receive events are placed in a joint mixed interrupt event queue and are processed in the order in which they are received.
Placement of an event in the mixed interrupt event queue includes the need for processing of the event. As events are processed, they are placed in a completion queue for an interrupt handler to complete processing of event data. Both completed send and receive events are placed in the completion queue in the order in which they are processed from the mixed interrupt event queue (108). Processing of send or receive data in the completion queue invokes an interrupt handler which utilizes a single thread to periodically poll the completion queue to determine if there are items present in the completion queue to be processed (110). In one embodiment, the thread that monitors the completion queue is inactive, i.e. sleeps, when the completion queue is empty and is woken up by placement of any new data in the completion queue. If it is determined that there is no data present in the completion queue, the interrupt waits a preset time interval (112) before it returns to step (110) to poll the completion queue or the thread goes to sleep and waits for any new data in the completion queue. However, if it is determined that there is an item present in the completion queue for processing, it must be determined whether the next data item present in the completion queue is associated with an originating send event (114). In one embodiment, the determination at step (114) may solicit whether the next data item in the queue is associated with a receive event. A positive determination at step (114) is an indication that the send has been completed and a send handler in the interrupt handler is invoked to process the send data (116). The send interrupt handler needs to find the buffer pointer of the send data (118), validate the data packet (120), and release the data packet (122). Alternatively, if it is determined at step (114) that the next data item is not associated with completion data from a send event, then by default the next data item in the completion queue is associated with completion data from a receive event (124) and the interrupt handler needs to process the data associated with the receive interrupt handler (126). The receive interrupt handler needs to find the buffer pointer for the data being received (128), allocate a new buffer for a new direct memory access (130), process the data packet (132), and pass the data packet to upper layer protocols (134). Accordingly, a single interrupt handler polls a single completion queue to process data from both send and receive events, and forwards the next item in the queue to the appropriate send or receive handler in the interrupt handler.
FIG. 2 is a block diagram (200) illustrating a prior art device queue in relation to an interrupt handler. As shown, there are two forms of an originating event that may generate a hardware interrupt, a send event (202) and a receive event (204). Either of the events may generate a hardware interrupt (206). Both send events and receive events are placed in the same interrupt event queue (208). As shown in the example, there are four events, event1 (210), event2 (212), event3 (214), and event4 (216) in the queue (208). In this example, event1 (210) is a send event, event2 (212) is a send event, event3 (214) is a receive event, and event4 (216) is a receive event. As noted above, as the events in the mixed interrupt event queue (208) are processed, they are placed in a completion queue (218) for completion of processing of associated event data. The completion queue (218) is a single queue for processing of event data, and includes completion requests for originating send and receive events. The interrupt event queue (208) is different from the completion queue (218), as the interrupt event queue processes events and the completion queue processes completion of event data. As shown in this example, the completion queue (218) has four events that require completion. The events are shown in the order of receipt. Completion event1 (220) is completion of processing of data from event1 (210), completion event2 (222) is completion of processing of data from event2 (212), completion event3 (224) is completion of processing of data from event3 (214), and completion event4 (226) is completion of processing of data from event4 (216). Accordingly, the prior art queues associated with processing events and data for completion of the events are both mixed queues that process receive and event data in a first in first out order.
Furthermore, as shown in FIG. 2, the interrupt handler (250) has a send handler (260), a receive handler (270), and a thread (280) to periodically poll the completion queue (218) for presence of a data to be processed by the interrupt handler. If the thread (280) detects presence of an item in the queue (218) associated with completion of a send event, then the item is forwarded to the send handler (260) for completion. Similarly, if the thread (280) detects presence of an item in the queue (218) associated with completion of a receive event, then the item is forwarded to the receive handler (270) for completion. Accordingly, a single thread (280) in the interrupt handler is responsible for monitoring the completion queue for items associated with both originating send and receive events.
As shown above, the prior art process for processing data associated with a hardware interrupt has a single queue for executing both send and receive events, and another single queue for completing processing of data associated with such events. In addition, the interrupt handler is limited to a single thread for polling the completion queue. This structure restricts the interrupt handler to initiate data processing from items in the completion queue one item at a time, whether the items are associated with completion of data processing from a receive event or a send event. Accordingly, there is a need to accelerate processing of data in the completion queue by separating processing of completion data based upon whether they are associated with an originating send event or a receive event.